The ability to act quickly and decisively in today's increasingly competitive marketplace is critical to the success of any organization. The volume of data that is available to organizations is rapidly increasing and frequently overwhelming. The availability of large volumes of data presents various challenges. One challenge is to avoid inundating an individual with unnecessary information. Another challenge it to ensure all relevant information is available in a timely manner.
One known approach to addressing these and other challenges is known as data warehousing. Data warehouses and data marts are becoming important elements of many information delivery systems because they provide a central location where a reconciled version of data extracted from a wide variety of operational systems may be stored. As used herein, a data warehouse should be understood to be an informational database that stores shareable data from one or more operational databases of record, such as one or more transaction-based database systems. A data warehouse typically allows users to tap into a business's vast store of operational data to track and respond to business trends that facilitate forecasting and planning efforts. A data mart may be considered to be a type of data warehouse that focuses on a particular business segment.
Decision support systems have been developed to efficiently retrieve selected information from data warehouses. One type of decision support system is known as an on-line analytical processing system (“OLAP”). In general, OLAP systems analyze the data from a number of different perspectives and support complex analyses against large input data sets.
There are at least three different types of OLAP architectures—ROLAP, MOLAP, and HOLAP. ROLAP (“Relational On-Line Analytical Processing”) systems are systems that use a dynamic server connected to a relational database system. Multidimensional OLAP (“MOLAP”) utilizes a proprietary multidimensional database (“MDDB”) to provide OLAP analyses. The main premise of this architecture is that data must be stored multidimensionally to be viewed multidimensionally. A HOLAP (“Hybrid On-Line Analytical Processing”) system is a hybrid of these two.
ROLAP is a multi-tier, client/server architecture comprising a presentation tier, an application logic tier and a relational database tier. The relational database tier stores data and connects to the application logic tier. The application logic tier comprises a ROLAP engine that executes multidimensional reports from multiple end users. The ROLAP engine integrates with a variety of presentation layers, through which users perform OLAP analyses. The presentation layers enable users to provide requests to the ROLAP engine. The premise of ROLAP is that OLAP capabilities are best provided directly against a relational database, e.g., the data warehouse.
In a ROLAP system, data from transaction-processing systems is loaded into a defined data model in the data warehouse. Database routines are run to aggregate the data, if required by the data model. Indices are then created to optimize query access times. End users submit multidimensional analyses to the ROLAP engine, which then dynamically transforms the requests into SQL execution plans. The SQL is submitted to the relational database for processing, the relational query results are cross-tabulated, and a multidimensional result set is returned to the end user. ROLAP is a fully dynamic architecture capable of utilizing precalculated results when they are available, or dynamically generating results from atomic information when necessary.
The ROLAP architecture directly accesses data from data warehouses, and therefore supports optimization techniques to meet batch window requirements and to provide fast response times. These optimization techniques typically include application-level table partitioning, aggregate inferencing, denormalization of data structures, multiple fact table joins, and the use of specific RDB optimizer tactics which vary with each particular brand of relational database.
MOLAP is a two-tier, client/server architecture. In this architecture, the MDDB serves as both the database layer and the application logic layer. In the database layer, the MDDB system is responsible for all data storage, access, and retrieval processes. In the application logic layer, the MDDB is responsible for the execution of all OLAP requests. The presentation layer integrates with the application logic layer and provides an interface through which the end users view and request OLAP analyses. The client/server architecture allows multiple users to access the multidimensional database.
Information from a variety of transaction-processing systems is loaded into the MDDB System through a series of batch routines. Once this atomic data has been loaded into the MDDB, the general approach is to perform a series of batch calculations to aggregate along the orthogonal dimensions and fill the MDDB array structures. For example, revenue figures for all of the stores in a state would be added together to fill the state level cells in the database. After the array structure in the database has been filled, indices are created and hashing algorithms are used to improve query access times.
Once this compilation process has been completed, the MDDB is ready for use. Users request OLAP reports through the presentation layer, and the application logic layer of the MDDB retrieves the stored data.
The MOLAP architecture is a compilation-intensive architecture. It principally reads the precompiled data, and has limited capabilities to dynamically create aggregations or to calculate business metrics that have not been precalculated and stored.
The hybrid OLAP (“HOLAP”) solution is a mix of MOLAP and relational architectures that support inquiries against summary and transaction data in an integrated fashion. The HOLAP approach enables a user to perform multidimensional analysis on data in the MDDB. However, if the user reaches the bottom of the multidimensional hierarchy and requires more detailed data, the HOLAP engine generates an SQL statement to retrieve the detailed data from the source relational database management system (“RDBMS”) and returns it to the end user. HOLAP implementations rely on simple SQL statements to pull large quantities of data into the mid-tier, multidimensional engine for processing. This constrains the range of inquiry and returns large, unrefined result sets that can overwhelm networks with limited bandwidth.
As described above, each of these types of OLAP systems are typically client-server systems. The OLAP engine resides on the server side and a module is typically provided at a client-side to enable users to input queries and report requests to the OLAP engine. Current client-side modules are stand alone software modules that are loaded on client-side computer systems. One drawback of such systems is that a user must learn how to operate the client-side software module in order to initiate queries and generate reports.
Although various user interfaces have been developed to enable users to access the content of data warehouses through server systems, many such systems experience significant drawbacks. One system enables the user to access information using a network interface device (e.g., a web browser). Such systems provide the advantage of allowing users to access the content of a data warehouse through existing web browser applications residing on their desktop or other personal computer connected over a network to the server system. Such systems however suffer from various drawbacks.
In existing web-based user interfaces, a user inputs a query or report request through the web browser, the web browser initiates the report to the server, and waits until the report finishes before providing results back through the web browser to a user. While the web browser is waiting for the report, the web browser “locks up,” thereby requiring that the user open another browser window if another site or page is desired to be opened. Accordingly, if the delay between the report initiation and completion is lengthy, some users may incorrectly assume that the delay is caused by an error, when in reality the delay may simply be caused by the complicated nature of the query. Users may become impatient and resubmit the report by selecting the reload or refresh feature of the web browser. Current systems treat each such request separately and, therefore, each time the user resubmits a request, another query for the same information is submitted to the server. Because the reason for the delay in most circumstances is the size or complexity of the query, the server is then hit with processing multiple complex or large queries simultaneously when only one such query or report is desired. Accordingly, these multiple reports tax server resources unnecessarily.
Another drawback this example illustrates is that current systems focus on requests. Accordingly, each request is treated as a different request that is submitted to the server for processing. Accordingly, identical requests initiated by different users are submitted to the server system for processing, thus utilizing the server resources twice to generate the same report. These and other drawbacks exist with current web-based data warehouse/server system user interfaces.